bpo-43224: Implement PEP 646 changes to genericaliasobject.c#31019
bpo-43224: Implement PEP 646 changes to genericaliasobject.c#31019Fidget-Spinner merged 19 commits intopython:mainfrom
Conversation
JelleZijlstra
left a comment
JelleZijlstra
left a comment
There was a problem hiding this comment.
Thanks for splitting up the PR, I think this will be easier to review.
I think you should add a separate news entry for each PR, something like "Allow unpacking GenericAlias objects. Part of PEP 646."
Co-authored-by: Jelle Zijlstra <jelle.zijlstra@gmail.com>
Co-authored-by: Kumar Aditya <59607654+kumaraditya303@users.noreply.github.com>
Co-authored-by: Kumar Aditya <59607654+kumaraditya303@users.noreply.github.com>
|
@pablogsal Might be good to have your eyes on this too, to make sure we get GC correct :) |
|
Apologies for the slow reply - it's been a busy couple of weeks! Taking a look at this feedback now. |
|
@Fidget-Spinner Done. |
JelleZijlstra
added
the
🔨 test-with-buildbots
|
🤖 New build scheduled with the buildbot fleet by @JelleZijlstra for commit 1102d27 🤖 If you want to schedule another build, you need to add the ":hammer: test-with-buildbots" label again. |
bedevere-bot
removed
the
🔨 test-with-buildbots
|
Now it's failing tests because of #31801, sorry for that! Once that's merged you'll have to merge main into your branch again. |
|
Main is unbroken now, but I'll see if the current refleak builds say anything; maybe they still tell us something useful even if test_asyncio fails. |
|
That was fast! I've re-merged. |
JelleZijlstra
added
the
🔨 test-with-buildbots
|
🤖 New build scheduled with the buildbot fleet by @JelleZijlstra for commit eda60f9 🤖 If you want to schedule another build, you need to add the ":hammer: test-with-buildbots" label again. |
bedevere-bot
removed
the
🔨 test-with-buildbots
|
The refleak buildbots are still unhappy |
|
Seems like there's a refleak on main. I'll try to find it. |
|
@mrahtz I just merged the fix for the refleak into main. Can I trouble you to merge main into this PR again please? |
|
@Fidget-Spinner Wow, that was also fast :) Done. |
AlexWaygood
added
the
🔨 test-with-buildbots
|
🤖 New build scheduled with the buildbot fleet by @AlexWaygood for commit 5fe058e 🤖 If you want to schedule another build, you need to add the ":hammer: test-with-buildbots" label again. |
bedevere-bot
removed
the
🔨 test-with-buildbots
|
Looks like the buildbots are finally happy! 🎉 |
|
Congrats @mrahtz ! |
|
Fantastic - thanks @Fidget-Spinner! |
8 participants
These are the parts of the old PR (#30398) relevant to starring tuples. This allows us to do things like
*args: *tuple[int, *Ts](whereTsis aTypeVarTuple).@gvanrossum Pradeep and I were wondering what the best way of representing a starred
tuplewould be, given that we'll also need a representation of a starredtyping.Tuplefor backport purposes. Should we try and make both*tuple[int]and*Tuple[int]refer to the same thing (I guess something we'd add totyping.py), or is it ok to have them refer to different things (as this PR currently assumes, creating a new native type for*tuple)?Until the PR with the grammar changes has been merged (#31018), the tests for this look a little awkward. Happy to wait until that PR has been merged to be 100% sure this is correct.
@Fidget-Spinner Would you be happy to review this?
(Also, could someone add the 'skip news' label? The news item is being added in the grammar PR.)Jelle suggests creating a separate news item for each PR, so I've added an item for this one.https://bugs.python.org/issue43224